SR – Stack requests

1 Introduction[//]

For some libraries, particularly larger Academic libraries, there may exist significant material which is not available on open access shelves. Typically, readers are required to enter “requests” for such material, which must be retrieved and delivered by library staff. One of the key functions of the stack request processing is to “deliver” this request (e.g. by printing it out) to a service point most appropriate to the location of the work.

Depending on the location of this material, the time taken to deliver may be measured in minutes, hours or even days. Another key task of the system is to offer some guidance as to estimated delivery schedules.

Such material will be delivered to an appropriate location, either for subsequent collection by the reader or for direct delivery to, for example, a specified table in a reading room.

According to library policy, material may be issued in the regular way and be removed from the library or may be used within the library only. In this latter case, the system needs to handle situations where the borrower wishes to read the material on subsequent days, or where there exists a queue of borrowors for the item.

The system must also allow the borrower to monitor the progress of their request and to inform them automatically when the material is available for collection.

Not only must the system allow for the delivery of material this way, but it will also control this process. For example, the staffing of a service point may only allow for so many requests to be managed per day, so the system will be capable of applying limits on the number of requests placed to a service point. It must  also allow for emergencies – for example, if a delivery van breaks down, so that borrowers do not continue to place requests in the expectation of a quick delivery, when there is no chance of the library supplying the material.

Finally, although the system is designed to allow the library to monitor and control  requests and their delivery in a very detailed and prescribed way, the system configuration can be simplified and straightforward requiring little monitoring.

1.1 Functional overview[//]

The following overview sections attempt to outline fairly briefly the main functions of the system. The first section describes the assumed working environment of the system with regard to stack requests and gives an idea of the aspects of the system regarding the management of the requests and the delivery of the requested material itself. The second section describes how requests can be entered in the system, with some of the most important features highlighted, and also how requests can be monitored and tracked. Later sections restate in detail the settings, commands and screen displays used ..

Notes:

1. In the following descriptions, the wording “Delivery point”, “Reading room” and “pickup location” are used more or less interchangeably; they refer to the same “place” but the different wording is used contextually (so, for example, from the point of view of the library, the item is sent to a “delivery point” but from the borrower's point of view it might be a “Pickup location”.

2. The screen examples shown are for illustration. They may not always contain entirely sensible data, nor may one screen shot be fully consistent with another.

1.2 Physical structure[//]

As an example, we consider a reading room with named tables. The reading room has some open access shelves, which can be handled in the regular way. It also has two reserved stack locations – a local closed access stack and a remote stack (the “University deposit”).

Material from the local stack must be requested explicitly but can be fetched and delivered more or less immediately; material from the remote stack is delivered by van at 10.00 a.m. and 2.00 p.m.

Material from the University deposit is found and retrieved from two “service” points at that deposit  - one “Upstairs” and the other “Downstairs”. Material is retrieved and delivered to the Shipping area, from which it is taken by van to the Reading Room stack and thence to the service point, to the specified reading room table.

The system therefore has the concept of a number of ‘service points'. A service point may be either :

·                a “Stack” service point – i.e. within the stack itself and deals with the retrieval and reshelving of the material (e.g. “Upstairs” in the example).

·                an “Intermediate” service point – e.g. the “Shipping” service point

·                an “Issue point” – e.g. the Main reading room service point.

In the above example, whilst the Reading room stack could be logically considered separate from the main issue desk, in practice the retrieval of material is so immediate that staff consider this point both a  local stack and the issue desk.. For this reason, a service point may be considered to act as several or all of the above functions. 

The “Main reading room” stack and the issue desk can therefore be configured as the same “service point”. And in this case has all three attributes of service points – it is its own specific stack location, it acts as an issue point and is an intermediate service point in the sense that material is delivered there from the remote stack.

What are the key attributes of a service point then ?

For a Stack service point, there are two main areas that we need to know about.

The first is what material is handled by this service point  Here we define the book locations which are covered by this service point.

For example :

·                Upstairs handles material with a location of “UnivDeposit”, call numbers “001. – 449”, whilst “Downstairs” handles location “UnivDeposit”, call numbers “449” onwards

·                The Reading room stack handles all material with a location of “Central Reading Room”.

This allows the system to send the request to the right service point (e.g. by printing a request at a printer defined for the service point). There are many other aspects which can be configured for the service point –for example, its “availability” – when is the service point manned – what days, or times.

The second consideration is the actual delivery of the material.Tthe system allows the library to define “routes” from the Stack location/ service point to the issue location. For example, in the above case, a route might be

Upstairs è Shipping è Main reading room

For each step in the route the library can define some typical processing times allowing the system to calculate an expected delivery time, in combination with the “calendar” of availability.

For all service points, the system can record typical times required to manually process the requested item (e.g. loading into crates, loading onto van); it can also record the typical time to deliver the material between service points.

For example, the timing for the above route might be made up of

Request placed at 11.00 am

Time to retrieve the item from “Upstairs”               1 hour               12.00 am

Time to send from Upstairs to Shipping                ½ hour              12.30

Processing at “Shipping”                                     ½ hour              13.00

Next delivery time                                                                                  14.00

Time to send from “Shipping” to “Reading Room”   2 hours             16.00

Processing at “Reading room”                             ¼ hour              16.15

            Expected availability                                                                   16.15

Delivery / Reading room locations

The concept of a route is useful in determining the pickup or final delivery location of the material requested. If a borrower, for example, places a request for a work over the Internet using the WebOpac knowing the location of the work, then the system can offer the user possible collection locations based on the routes defined in the system.

Batching the delivery of requests

In order to save manual processing of individual items, recording their progress to the delivery location, items may be “issued” to boxes, and the subsequent progress of the box as a whole can be monitored.

Processing at intermediate service points

The system is designed such that it is expected that items received at an intermediate service point would be “checked in”. This allows the progress of a request to be monitored (and displayed to the users – both staff and public).

However, this is not absolutely required. The specification of intermediate service points in a route would only be used as an aid to determining the expected delivery time. If items are identified at an intermediate service point, then the system can recalculate the expected delivery time starting from that service point to its final delivery location.

Placing and monitoring a request

Requests for material may be entered either by staff, using the main Vubis applciation, or by borrowers themselves using the WebOpac.

According to various defined options, the following features are available :

·                Requests may be placed for material found in the catalogue OR appropriate bibliographic information may be manually entered when not all such material is fully catalogued. Subsequent processing can be tailored according to this context . For example, it may take considerably longer to find material which is not fully catalogued.

·                Borrower's may “post-date” requests – that is, they may request material for some date in the future when they are planning to visit the library.

·                The system allows borrowers to “self-register” i.e. to enter their own details and then place a request for material, subject to further checks of course by the library

·                A pickup or delivery location can be optionally selected by borrowers when more than one possible route is defined between the location of the material and delivery service points.

·                Borrowers may request a specific copy of a work, or may request the “title”, in which case the system will select an appropriate copy.

To expand this last point, the system will always allocate a specific copy for a request. If there are several copies of a title at, several locations, then the system attempts to determine which is the “best” copy to select and to give some guidance to the user to help in their decision. if there are multiple copies with possible different delivery locations the system will offer the user a choice of such locations, narrowing down the choices of locations available to the system.  Unlike the comparable situation for reservations, the system will NOT send “messages” to each possible location, waiting for the first such copy to be identified to the system.

Display of stack requests

Borrowers may monitor the progress of their request. They will be notified by a variety of means such as email or printed notices, when the material arrives at the delivery point.

Staff may search for requests in a variety of ways – including by borrower, by bibliographic details, by date. “Preformed” summaries are also offered – for example, a summary display of all active requests relevant to the current location of the borrower.

2 Parameters and configuration[//]

The following sections describe the system settings used to manage the stack request processing.

The AFO's involved are:

·                815

·                618

·                621

·                481

2.1 Initial installation[//]

Take the following steps for initial installation, but consult Infor first.

·                   AFO815 - Install ASR (Stack Request Module)  and use AFO151 to check and compile the newly installed  Request format

·                   Setup the System Wide  options - turn on "In use" flag  in AFO815

2.2 Define service points[//]

Stack service points

Decide  on which locations are to be considered as “Stack” locations i.e. which locations  are closed access. In addition, these may be further subdivided according to where the printed request is to be delivered.  If required,  define intermediate and /or delivery locations as well.

Service points are defined per circulation meta institution

AFO 618

·                   Define the Stack service points

·                   Use the General tab, and the Stacks tab to define specific characteristics of each service point.

Suggestion: Define the general structure / outline initially, and then come back to refine the specific details

Using the “Locations” option, define the Item locations which represent this service point.
Note that more than one item location range can be added to each service point.

Delivery / reading room

Define which locations are valid reading rooms or delivery points – for example, it may be that books from stacks can be delivered to every issue point. Define “names” for these issue points. There can be more than one at any location.

AF0 618

·                Define the Delivery type service points and their locations This allows the system to tell which service point you are at when you login.

** Note:  Service points available at login are defined as part of the Login Management and are defined on a per staff user basis in AFO611 – Login Management

Outputting the requests to the service points

A specific printer is allocated to a stack service point. One or more “Print processors” must be configured – see the general help on mailmerging for this. In order for a request to be printed, the printer must be visible to at least one print processor. It may be a printer connected locally to the Print Processor's workstation or there may be several printers shared on a network.

When these Print Processors are started, they will “tell” the server about the printers available.

In AFO 621, - Print processor maintenance

·                   Define the print processors available to the system. These are dedicated workstations and will further configured on the actual workstations.  hese will match the configuration names set up on the individual workstations dedicated to act as Print processors.

In AFO 621, - Maintain system printers

·                   Click on “Check for printers”.

The system will return with a list of printers is recognizes as Print processor Workstations

AFO 622, - Calendar definitions

Borrowers may place requests at any time of the day or night, but printing of the request may only be desired when the service point is manned.

A system calendar (AFO622)  may be defined to control when output may be produced.. Printers / service points may share a calendar. For example, a “CentralStackCalendar” for Basement, Upstairs and Downstairs.

In AFO 618, for each stack service point, select the output tab: define which printer to use, and which calendar to use.

In addition printing rota's may optionally be used to designate different printers for the same service point depending on time of day.

2.3 System routes[//]

Consider how the item gets from the Stack to the Reading room or delivery point.   Individual routes are define.

In AFO 618

Select each Stack service point, and use the “Routes” option.

Define a route for each reading room that is serviced from this stack location.

Define a description and a route end. Now click on the “Simple delivery calculations”

Check the option “use simple delivery calculation”.

A calendar is used to determine when is this route in use / active. The delivery calendar can be different from the print calendar.

In the processing delay field, define how long you expect it to take to delivery on this route. It may be defined in minutes (M) or days (D). For example, 60M represents 60 minutes or 1 hour.

Then specify how to calculate the expected delivery time when the  processing delay takes the expected delivery time to the next day according to your calendar (wrap around on open time)

Testing your configuration for routes

A test option lets you check what the system will predict for an expected delivery time, based on the specific route and the actual time that a request is placed. Use this to check that the system is predicting the dates/times that you would expect allowing for your calendar setup for the printing of the request and the route itself.

2.4 Notice sets[//]

A “notice set” defines the layouts of a set of related notices. There are two types of notice sets in the context of stack request maintenance – notices which are to be sent to a borrower, and the actual printed stack requests themselves.

Printing of the main notices for Stack request is handled by using mailmerge processing from an industry standard Word-Processing package (such as Microsoft Word). This allows the library to use Word-processing to design the layout of their stack request forms and allows for enhanced output such as  the Request number printed in barcode format, or to allow graphics and logos to be output.

Stack request output formats

For Stack request, we have the following printed or emailed outputs :

·                Stack request – printed

·                Stack request – reprinted

·                Stack request – post-dated

·                Stack request – for use when item put into transit between reading rooms

·                Stack request – for use when the item found for a request but transiently returned via the stacks locations.

·                Stack request – when item held back at the reading room

These are defined by specifying the full name of a Word (or similar) mailmerge master document. The “notice set” is list master documents and their location for each of the required outputs.

Since the layouts may vary according to the location at which they are required, it is possible to define any number of “Notice Sets” – which are then linked to the relevant service point. 

Reader / Borrower notices

The notice set for borrower notices is linked to the Stack request code and indirectly to the borrower category which allows for tailored contents of the master document and control over which document types are required.

For example, the wording might be different when addressed to an organisation rather than an individual; or for staff placed requests, notices about a request temporarily suspended may not be required.

Borrower notices available are

·                   Request available

·                   Request available (Reservation)

·                   Request cancelled

·                   General message

·                Acknowledgement

Note: “request available” messages can be sent by SMS text messaging.

Diagram

AFO 618 – Notice sets

Having defined the printers and service points, we now need to define WHAT to print.

This is configured by the contents of the Mailmerge templates. A sample set of notices forms part of the installation. For example :

As documented in the general help on mailmerging, a copy of these is available in a separate Windows directory and visible to each print processor workstation.

The actual source file names may be different. If  additional versions e.g. multi-lingual ones are required, definie a different source document for each language. In AFO 618 / Notice sets – Language.

The source document location for the print processor is stored on the server and not specifically for each print processor. The path and names of these source master documents must therefore be recognisable by each print processor.

There are three main approaches to this :

1.              Put copies of the files named identically on the C: drive of each print processor

2.              If there is a network available to all Print Processors, then put them on a common shared drive (e.g. G:\Notices\...)

3.              Or put them in different places, and define a DRIVE MAPPING that is identical for each Print Processor.

Option 1. means maintenance of the source master documents is done individually per workstation allowing the layout or a different heading or logo each stack service point / Print Processor.

Options 2 and 3 mean all source files are identical.   Additional networking configuration is required for each workstation to allow for access to a common path and shared network directory.

2.5 Cancellation codes[//]

Use AFO 618 / Cancellation codes to define some “reasons” for cancellation of requests.

One of these should be configured to be the reason applied when a borrower cancels their own request from the WebOpac. This must be added to the General options in AF0 618.

2.6 Borrower setup[//]

In AFO 481 – Miscellaneous, there are two options related to stack requests.

Stack request codes per borrower category determines which borrower categories are allowed to place stack requests.
These codes must first be defined in AFO 618 - Stack request codes.

With Stack request fees determine specific costs for those borrower categories that are allowed to place stack requests.

Depending on the parameter in AFO 815 Stacks management – System wide options “How many days back to show request summary in 431 the borrower summary of reservations (on the detail screen in AFO 431) will also show request counts over a given period.

This is total number of reservations and the total number of Requests, Reservation request, Deleted, and Expired.

AFO 618 - Stack request code  also allows you to manage the automatic creation of blocks against the borrower, as follows :

Block on number of requests not collected                 [10 ]

Cut off period for determining block                [730]

If a borrower fails to collect requested items, then the system will create a “block” (in the usual way) against their record. This block will ONLY apply to the ability to place stack requests.

The “block on number of requests” above determines the number of these occurrences, but based on the “period” defined e.g. in the above case, they are not allowed to miss collecting items 10 times in a 2 year period.

An additional setting on the request display, on the Client tab will show the date and time of the block. This can be cleared by a staff member to reverse the block. Note that this means that the block as a whole cannot be cleared, but the setting on the individual requests are cleared, potentially, therefore, clearing the block.

2.7 Optional extra's[//]

The rest of the settings are optional should further refinement of the system be required.

More on Routes

The following is a general overview of some of the advanced features for managing routes. Consult the detailed documentation for more information.

1. Returning the items to the stack

A route from Stack A to Reading Room Z is initially defined to get the item to the delivery point or Reading room. . The system attempts to calculate expected times for return from the Reading room by “reversing” the steps from A to Z.    A  separate table can be defined  for the reverse journey.

2. Processing patterns

The simple calculation allows for a simple “one-off” delivery period. It is possible to define processing patterns which take account of the nature of the material requested and to define specific tasks within the processing of material from stack to reading room. For example, you can tell the system that it will take longer to retrieve journals from the stacks than monographs since there may be more searching time to find the requested journal part.

3. Intermediate steps

If material from the stacks is processed to intermediate locations (e.g. from the specific location in the stack to a shipping area), then you can define intermediate locations and the delays involved in moving the material between each location.

For example, a van delivery is required with a specific route.  Define specific times when a van is expected to collect items and/or when it is expected to arrive at a service point.

Suspension of routes

Use AFO618., Suspension code to define reasons for suspending a route temporarily. One example might be where there is a power outage in the stack location where no further requests can be placed on that route until the suspension is lifted.

Routes may also be automatically suspended when there has been too much “traffic” –either based on the number of requests/day and/or on the number of currently active requests.

It is also possible to suspend all routes in a single operation via AFO 816.

Limitations

In AFO618 – Service point maintenance – Maximum reservation requests by item category you can specify the maximum length of a reservation queue according to the category of the item being requested.

When placing a request against an item, the system checks this maximum against the number of requests queued against the item. The setting used is determined for the service point against which the request is being placed.

You can use the option in AFO 618 – Service points - Authorization by item and borrower category to specifically exclude item categories for specific types of borrower.

Both these parameters can be set for each SERVICE POINT separately. The name of the service point is displayed at the top of the form.

Loan status codes

AFO 481 – loan status code settings – allows you to specify for any code that an item with that particular status may not be requested.

3 Placing a request[//]

Requests are placed using AFO421, as for placing a regular reservation. Selection of a title leads to the normal reservations screen.

There are four main possibilities with respect to placing a stack request or a reservation at this point.

·                The title has no holdings defined – in which case no stack request is possible.

·                The title has holdings but none at a stack location

·                The title has holdings only at one or more stack locations

·                The title has both stack “closed access” and regular “open access” locations

In addition, the system considers the actions required when there are active requests for all stack items or  for a post-dated request.

How does the system determine if the holdings are at a stack location

A Service point is defined by a list of locations, and that certain service points are Stack service points.

These may be defined at the Location or Sublocation or Shelfmark range.

In determining whether the holdings for a particular title are or are not at a stack location, the system only considers the Location and Sublocation levels. If at least one Stack based service point is defined to refer to holdings at one of these levels, then the system will assume that all holdings at that level are stack locations.

The shelfmark range is considered subsequently to determine which service point might be appropriate..

Continuing to place the request

There are two relevant command icons on the screen displayed, one which allows a reservation to be placed, the other to place a stack request.

If the AFO815 – System wide option to allow normal reservations to be placed on a stack item is checked, then the staff member may always place a reservation.  If not, then this is only allowed on items NOT in the stack.

.

Just to define precisely the rules … if there are NO items for the title, then a reservation may be possible (according to library policy). A stack request is never possible – since this is for a specific date and activity. On the other hand, if there are only stack items (and reservations on these are NOT allowed), then a reservation is never allowed – even if there is a copy on order.

If a reservation is selected (subject to the above criteria), then if reservations on stack items are allowed, then all stack items are made available for the reservation (in the regular way); otherwise such items are excluded from the possible items shown in subsequent displays and processing screens.

The system then asks for the borrower to be entered, as for a regular reservation.

If the request is for an external reader/borrower, then the system assumes that the staff member has already added them as a temporary library member in AFO431.   A borrower record must already be present in order to proceed. .

Checks on the borrower's record

The Borrower's record is checked for blocks, valid membership and so on as for the placing of a regular reservation. The system ensures that their borrowing privileges allow them to actually borrow the items requested..

This includes a check for the specific block against placing a request.

Eligibility checks

The system will also check maximum number of reservation requests allowed, authorization by item category/borrower category as well as maximum number of requests/reservations allowed based on the stack request code in use.

Inputting the Stack Request

The precise layout of the form depends on the various options activated for the request. The example following is the most general one.

Delivery location                         This is the required delivery service point for the item; if the current service point is valid for the selected item, then this is offered as the default (regardless of the shortest delivery time).

Table                                        A dropdown list of the tables defined for the above service point. A blank (i.e. not known) entry is always acceptable. If no tables are defined, then this field is protected.

Expected delivery date                This shows the delivery date and time calculated by the system.

Required date and time               This allows for the manual input of a required date and optionally time. The system checks that this is greater than the expected delivery date and time. These are hidden if the stack request code for the reader disallows postdating the request.

Priority                                      Used only when there is a request queue – see discussions below.

Volume number / year                Allows for the entry of additional specific volume information

Number of parts                         Allows entry of number of pieces if known, if multiple journal parts requested.

Reader's note                            Additional information from the reader

Staff note                                  A staff note

The List button allows a different delivery location to be selected, using this button leads to a popup display of the other possible routes and an estimated delivery date and time.

From this display a different delivery service point can be selected.

Note: this does NOT allow for any delay in getting the item to the actual table as defined in the Table configuration (AFO618 – Service Point Maintenance – Tables option for Delivery Type locations).

If a line is selected, return to the previous input screen for completion of the request, at which point the system will redisplay the request in the main request display screen. Only on exiting this screen is the request printed.

Entering a request for non-catalogued material

In order to make a request for material which has been found (for example) in a card catalogue and is not available online, it is necessary for relevant bibliographic and call number data to be entered to allow the item to be retrieved.

This process is initiated by using the [New record] button on the bibliographic search screen for AFO421.

This New record button is only offered if the institution is using the Stack request processing.

The system prompts in the usual way for a borrower to be selected.Enter the bibliographic details for the required item.

Title is mandatory but additional details are required before the request is finally valid.

Location of the item must be entered.  The default location shown is taken from the end point of the first route found (if one exists) for the current service point .

The entry of institution / location and call number is MANDATORY at this point.  No checks can be made as to the current status of this title    On completion of this form, the user is taken to the main request display screen.

Route suspended

If the route is suspended, then a warning is displayed on the main input form and this is also displayed on the delivery room selection list.

Example:

Route suspended from 13 Feb 2009 – 18 Feb 2009

Power failure in the stacks

Where the dates are taken from the route and the wording from the “suspended code”.

In this case, the system treats the item as “unavailable” and continues to treat the request as if there were current active requests, as described in the next sections.

AFO 816 allows for ALL routes to be suspended in a single operation. For this you can also optionally select a suspension reason code. In that case the message associated with the reason code will be displayed to borrowers attempting to place a request.

Placing a reservation on the stack title

If current active requests exist for all stack items, the system reports this after the borrower has been selected. There are two choices here: either the borrower can place a reservation i.e. to get a copy when one becomes available, or to place a post-dated stack request.

NOTE

If a reservation is placed in this context, then it is copy specific i.e. it must be placed on a specific copy of the item(s) in stack.

4 Processing requests[//]

Most stack request maintenance functions are to be found in AFO 813. This has the following menu options

·                   Alerts Processing

·                   Stack request display

Alerts processing is reserved for future use. Below is a description of the stack request display options.

4.1 Overview of the workflow[//]

From Stacks to Library

1.              On printing of the request slips, the book stacks staff attempt to find the item(s) requested.

2.              The essential workflow in the movement of the item from the stacks to the recipient library is that the item is checked out when moving out from a location, and checked in when coming into a location. At all points the check out and check in routines will check the status of the item being wanded to see whether that item has a current request in process.

3.              When the item is ready to be shipped, it is checked out from the stack location. At this point, the request file is checked to confirm that this item has an active request for it. If not, the user is warned, and the item can be put aside for return to the stacks.

4.              If batching of books is used, the system behaves differently according to the situation; when checking items out of the stacks, entry into the checkout process retrieves and displays the next available batch number; the first item then checked out defines the route that the batch will take; this is prompted and must be acknowledged by the user. Subsequent items are then checked that they conform to this route. The batch is closed by leaving the checkout process, at which point the user is asked whether they wish to add a note to the batch

5.              At this point, the status on the item record is changed, indicating that the item is in transit from the stacks to the recipient library. The item is shipped out, and its status changes accordingly.

6.              On arriving at the next location, the item processed accordingly. If this location is an intermediate station, the individual item or batch can be processed in and out, or directly through the station. Again, the implied route is displayed, and must be acknowledged by the user. At the Reading Room, the items, if batched, are unpacked. At this point, the item status again changes (it is now awaiting collection or pickup by borrower).

7.              The item is now held behind the counter for the period defined in the Processing Pattern for the current Stack Location code.

8.              If during this time, another borrower requests the item from the counter, the system checks the whether the system configuration allows for other borroewrs to “jump the queue”.

9.              If the item is not requested at the library either by the current requestor or by any other borrower, or the item is returned after being consulted or borrowed by another reader other than the current requestor, then the item is checked in for return to the stacks. If the item is checked in from a current stack request, then the system will prompt the staff member to ask whether the item is to be retained for further consultation.  If yes,, the stack request just serviced remains current, i.e. the reader is still first in the queue.

10.          If there are other current stack requests for this item, at this location, the system notifies the staff user of this, and the item is held back by the library, the new stack request (first in line) becoming the current one.

11.           ‘Local' requests for the item take priority over current requests for the item at other service points, the system checks line 11 in the processing pattern. If this is set to 0 or blank, then the item is put in to transit ‘normally' to the new location. If set to 1, the item is returned to the stacks. On being checked in there, the new stack request is then activated.

12.          If the item is transited directly, or via the stacks, to satisfy another stack request, then, on the item arriving at the new location, we start again at 1 above.

13.          If at this point, however, there are no other current stack requests, then the item is cleared for return to the stacks.

4.2 Printing the request[//]

When the request has been entered (and confirmed) then it is necessary to output the request directly to a printer serving the stack service point determined.

If the request is post-dated, then the printing is delayed.

Background printing

Printing is managed by the Stack Request background processor. This task, much like the Reservations messaging processing, runs continuously scanning the requests to see for which ones a request notice is required.

From the Stack location, the printer required is determined and the output is prepared.

The actual generation of the notice is handled by a “print processor” which actually carries out the mailmerge processing and sends the result to the requested printer. This processing is described in the general help on mailmerging.

Reprints

For REPRINTS, the system does NOT go through the background processor. These are processed directly and the staff member requesting the reprint is taken through the standard type of dialogue for output generation.

Printing a request which is queued

If an item is requested which is already on loan (or on its way) to a reading room, then there is no point printing the request at the stacks location .   However, it may be necessary or appropriate to print a request slip.

Post-dated requests

For post-dated requests, print time needs to be sufficiently far beyond the requested date to ensure that the item arrives in time.

This delay is a function of the actual route concerned so the system asks for a fixed print time, defined in the route settings for a service point in AFO618 under the Post dated print time.The entry tells the system how many days before the required date and at what time the requests should be printed. For example, when the delay is set to 1 Day, the system will print today  at 10.00 a.m. all those requests due tomorrow.

Note: Closed days are taken into account– so items due on Monday would be printed at 10.00 am on Saturday if the stack calendar states that Sunday is a closed day.

Route suspended

If the route allocated to a stack request is suspended, then any requests placed before the suspension but not yet printed are themselves suspended until the route active again..

4.3 Batching of requests[//]

“Batching” allows the system to group items retrieved to satisfy requests (or when returning the items to the stacks locations). The assumption is that such items are grouped into packages or boxes. It is then possible to record the progress of the batch as a whole rather than the individual items. For example, rather than having to record the receipt of each item at the reading room, staff need only record the receipt of the “batch.

Whether batching is in use is defined for each service point. It is possible to indicate that items are found individually when retrieving from “Upstairs” to be taken to “Shipping” but are then subsequently batched at the “Shipping” service point for transfer to their designated delivery point or reading room.

Items are “sent” to the next service point, using the Stacks Checkout function.  If batching is turned on, then the first item entered will cause the system to initialise a new batch; Subsequently entered items are added to the batch if they are for the same destination.

Batches currently “open” in this way are specific to the service point, BUT may only be active for one session.

When the Checkout function is exited, then the staff user is offered the option of closing the batch. The fact of shipping the batch may be recorded now , or it may be done later on. Similarly there is a command option to implement this processing.

If an item entered is for a different destination, the user is warned and offered the opportunity to close the batch, but this may be left open and a new batch started.
If a batch for this destination is already open, then the item will be added to that batch.

The system allows for a maximum of 5 such batches open at any time. Leaving batches “open” in this way will generate many warning messages to remind users that there are such incomplete transactions.!

Batches are assigned a unique reference which may be printed on a shipping note – optionally  in barcode form. This number may be keyed (or wanded) in Stacks checkin and checkout functions to indicate the receipt or dispatch of the group of items.

Once “batched”, individual items may be processed using the Checkout/Checkin functions. The item will be recorded as “removed from the batch” and is no longer considered to be part of that batch.  A warning is given to allow users to cancel the action.

When a batch is “closed” an option to enter a note is offered (and a note may be entered at any time for the batch). Any such notes are displayed whenever the batch is checked in or out.

5. Stacks checkin[//]

The Stacks Checkin function is initiated from AFO812 and is used to record the receipt of either an item or a batch at a particular service point. This may be used to record the initial retrieval of the item from the shelves at the initial stack location, or at any intermediate or final delivery location.

It is not necessary to use the checkin function at each service point along a route, except at the final delivery location. The system infers that items checked out from a location have been checked in, or if at the delivery location, the item has completed its designated route.

This shows an example input grid for the Stacks checkin.

Entries in this field may be one of:

·                An item barcode

·                A stack request number

·                A batch number

If it is an individual item the system displays the item's title, the time it was due “here”, the service point from which the item appears to have come, where it is due next, and its ultimate destination. The date and time last estimated is displayed.

The number of lines in the grid will default to 24. When the 25th item is entered, then the system will reposition the input position back to line 1; the next two lines are cleared (in preparation for the next item) – so at any time, the previous 23 entries are visible.

If the borrower has asked the request to be cancelled, then a message is displayed. This includes any item currently inside a batch. In either case, this is simply a warning – and one of the functions described below to remove items from a batch, or to interrupt the flow along the route must be carried out.

Checkin for post-dated requests

Once a request is “printed”, then it becomes “current”. As noted above, there is a setting on the route definition attached to the service point which determines WHEN the requests should be actually printed (e.g. last thing the day before, or first thing on the day).

If the system finds no “current” request, then it checks to see if there is a post-dated one. The staff user is offered the chance to use the post-dated one, regardless of how far in the future it is. If selected, the actual request will be printed immediately as it no becomes current.

Route suspended

If the route used is marked as suspended, then a warning message pops up ONCE for a given session in Vubis; otherwise the fact of suspension will have no bearing on subsequent processing. The suspension of the route only has relevance to the placement of new requests and to the printing of them.

Error handling

If the status of an item or batch is inconsistent with the attempted checkin, then an appropriate warning or error message is displayed.

Processing at the Stack or intermediate service point

The item / stack request is now “in processing” at the service point. The request is now set to a status of “In processing at < the service point>”  The item status is inferred from the linked request.

If the process was set to “pass through” then this and the steps described in the following Stacks Checkout processing section are carried out.

Processing at the reading room

The item is marked as available for the borrower. The request is set to a status of “Awaiting collection”. The borrower is notified of the availability of the item.

Notification

When an item is considered to be available (or all items in a group are), then an availability notice is sent by post and/or email according to the contact method defined for the request.

In addition a brief Text (SMS) message can be sent, if the library has the SMS messaging service configured.

The SMS text message is a simple message, e.g.:

Request ASR1243/2008 for History of the Uffizi now available until 12 March 2008 11:30.

This is sent in the contact language for the borrower – or the system default language.

There are two types of notice (Availability and Availability (Reservations)) defined.

In the case of a regular request being available, the system will NOT attempt to send an “available” notice by post – only the emailed version will be sent. On the other hand, when a reserved item becomes available, the system WILL send a printed notice (or an email).

In this situation, when the item is trapped, the system WILL warn the staff member that no availability notice will be sent (allowing them the option to contact the borrower by other means).

Notification delay

The notification to the borrower of the availability of the request can be delayed, typically by a few minutes, according to a setting for the service point. Particularly in the case of a batch checkin, it may subsequently be found that there is a problem with the item – for example, it is simply missing from the box or package. The delay therefore gives staff time to take some kind of action in this event.

6. Stacks checkout[//]

This handles recording the delivery of the item to the next or final service point.

It is at this stage that the “Batch” processing logic might be initiated. If so, the current batch will be displayed in the header part of the screen:

If this location is a delivery service point, then the checkout function is used to RETURN the item to its stack location; this is NOT a checkout to the actual borrower, which is carried out using the regular checkout function (AFO411). The system warns the staff user if an item, for which a current request exists, is entered in this screen, in this context.

As for the Checkin function, the system reports and warns the staff user if a request processed has been cancelled by a borrower.

6.1 Checking out the item to the borrower[//]

Regular checkout of a requested item

This is handled using the standard Checkout AFO411 (as is AFO412 for the returning item). The item barcode field  will accept a stack request number as a key to the item.

The stack request number is relevant to serial parts (often not barcoded) and also to non-catalogued items. Although the system will create a “dummy” item record (for technical reasons), it might typically be expected that the request number is printed on the slip attached to the work in barcode format. This need simply be scanned to issue the work to the borrower.

When the Stack location / Reading room is a single location

In Service point maintenance an option exists to define the service point as a combined stack location and reading room. (For example, where the stack is more or less directly accessible from the reading room and no real route is required.

In this case, the regular checkout process effectively marks the request as having been processed through its lifecycle. There is no need to use the Stacks Checkin / checkout processes.

Processing at Checkin

If the library allows borrowers to return the items for subsequent consultation, then the setting Subsequent consultation period for the service point is defined to have a non-zero value.

If this is the case, then on checkin the system will prompt a message asking if the borrower wishes to hold  the item for a further consultation.

If the item is held for further consultation, then effectively the request returns to its “Trapped” condition i.e. as if it had just arrived at the Reading room.

If there is a post-dated request or a queue of reservations, then this message may be modified in a variety of ways:

If there is a queue and the option “Requestor can reserve first” is turned off then the request for further consultation is suppressed.

Multipart / serials considerations

When the request is for one or more parts of a journal, then the specific parts are recorded in textual form only. It may or may not be clear whether the part(s)  being checked in represent the same items that are required for a reservation or post-dated request.

In this case, the system can determine that there IS a queue for the TITLE – and the system can only display the relevant parts of the requests and present a list.

In this situation, the “reserved” parts may overlap in full or in part with those being returned. The staff member may choose to select one of the displayed requests as being the one to manage. Alternatively, if one is NOT selected then the system assumes that the parts being returned do NOT overlap the reservation queue and allows “further consultation” .

When there is a partial overlap where some parts need to be returned to stacks, some parts may need to be sent to another reading room, and/or some parts retained at this reading room for a reservation,   the staff member must use the STOP option, which interrupts subsequent processing.

The returning request is marked as complete, but the subsequent requests are not “current”.. Each part must be “manually” sent to the relevant place and, as appropriate, any requests outstanding manually initiated.

Number of parts

If the number of parts comprising a request is set to greater than one, then the system always prompts the staff member to check that the number of parts returned is correct. Staff may choose to accept or cancel the return of material – but a “partial” checkin (4 out of 5 such items, for example) is not allowed.

Returning to the stacks

On checkin (via AFO 412), the item will be returned directly to the stacks IF

·                There is no queue of requests for the item

·                The setting “Hold at reading room if no queue period” is zero or empty at the reading room / delivery location.

If the item was NOT issued via the stack request processing, then the regular transit processing is initiated and the item must be checked back in at its home location using AFO462.

If the item was issued via the stack request processing, the item is “at the wrong location”; however the regular “ship item to xxx” is suppressed. A message reporting on the originating Stack service point pops up and the request treated as if it were first checked in for its return to the stacks. If the original location is a combined Stacks/Reading room, then the system assumes that the item is reshelved, as for a regular checkin.

When the route back to the stacks is marked as suspended, a warning message is displayed, BUT the processing continues as if the route were open.

Processing on the return to the stacks

When a new request is found during processing on the way back to the stacks location OR processing is delayed such that a postdated request is now within its “window”, a warning is displayed to indicate this situation. In such cases, when the request is printed, the full format request is printed.

Request queues

This section describes the processing when more than one borrower requires an item.

Post-dated requests

Post-dated requests are defined to use a  general “window” of required time. If an item is returned such that a request is found within that window, and  for the same reading room, then the item is trapped for that request.

Reservations

The Management of request queues can be set to “Treat equally” or to “According to queue”.

When "According to queue" is set, the item is trapped for the first request on the queue, where “Treat equally” uses the following priority sequence:

·                   Those for the current reading room

·                   Those with a higher priority (lower number!)

·                   Those that were placed first.

When there are no request for the current reading room, all other reading rooms are treated equally.Iif arequest found is for a different reading room, then there are 3 options :

1.              if the service point setting (we need to specify where this setting is here) is set to Direct, and there is no route defined from this service point to the required service point, then the item is simply put into transit (as for regular reservations)

2.              If the service point setting is set to Direct, and a route is defined between the two reading rooms, then the stack request routing functions are kicked off, as for a route from stack to reading room

3.              If the service point setting is set to “return to stacks”, then the item is processed as a return to stacks. The request “found” is made current.

If the request found is for the current reading room, then effectively it becomes current.

In both cases, an option to print a request notice is offered.

Retention Period:

NOTE: When the option is set to “treat equally”, the item is retained at the current reading room for the period defined in the “period to keep” setting. This MUST be defined . A notification is  sent to all borrowers for which there is a current request for this item, regardless of the expected delivery location recorded on the request.

The item is flagged as retained at this service point, but may be returned to the stacks at any point. If the “period to keep” expires without any borrower collecting the item, then the system fills  the first request, and continue as if the item were to be treated according to the reservation queue i.e. notify the individual explicitly.

Storing the item at the reading room

If there is a stack reservation or post-dated request for which the item should be held at the reading room, then the item is assumed to be available immediately for the borrower.

A request slip may be printed for the item. The borower is notified of the availability of the request as for the first arrival of the item at a reading room.

Interrupting and cancelling stack requests

General

At various points in the lifecycle of a request it may be appropriate to cancel or in some way interrupt the processing of that request. Some examples are :

·                The borrower no longer wishes to look at the item

·                The requested item is missing

·                The requested item doesn't exist (e.g. with respect to non-catalogued items)

·                There is an ambiguity in the request

·                The item is missing from a batch of requests in transit from A to B

·                The item wasn't collected in the period expected.

·                There was a problem in the delivery service (e.g. the van broke down)

·                A whole box of requested items has gone missing

The system distinguishes two status categories which may be applied to the request (and possibly the item for which the request is made). These are

·                   Cancellations     i.e. where the request itself is cancelled, for example a borrower cancellation, the item is destroyed, missing from the shelves.

·                   Temporary suspensions  e.g. where there may be a delay to satisfying the request, but initially, at least, we don't want to remove the request from the system completely. For example, where the item is missing from the expected batch of requests, the power has failed in the stacks themselves.

Temporary suspensions are only valid for “current” requests – and are not applicable to reservation requests. However, if there are post-dated requests, then it may be appropriate to “bump” the current request.. The system cannot decide such matters automatically and provides the necessary information in a manner convenient for staff to manage such conditions.

Individual requests may be cancelled or suspended from the main request display – or from he lists of requests which appear in various contextsCancellation or suspension may also be applied to All the requests for a given or for a given route as a single operation.

Cancelling the request

Cancelling offers the following input form

The section at the bottom of the screen will give some guidance as to the status of the request and the resulting “action” on the request and item. The option “Allow other reservations to capture this item” tells the system whether to find the next request in the queue to activate or whether to “interrupt” the processing.

The option “Replace this request as a reservation” allows the workflow through the system to be interrupted but also allows this request to be re-activated.

Both of these are offered according to the context of the cancellation (code) and may be suppressed, as described below.

In certain situations, the workflow of the request is such that the cancellation cannot be acted upon immediately. The request is marked with a “pending cancellation” status, and the actual processing carried out at some intermediate point. For example, suppose the item is en-route from service point A to B; then the request is still “active” but the actual cancellation (and the actions this implies) is acted on when the item is next physically “visible” to the system (for example, when the request is checked-in at the reading room).

Other processing also depends on whether there is a simple replacement copy for the item or whether this is the only copy of the title,  whether the borrower simply no longer required the material or if the copy has been destroyed / misplaced  and no longer available for any future requests.

Some scenarios are worked through below, starting with the simpler cases first.

Request being cancelled is a reservation, a postdated request or has not been confirmed.

In these cases, no direct processing has been carried out on the requested item(s) and the request is simply cancelled.

One of the following explanatory messages will be shown

·                This request is postdated and may be cancelled immediately

·                This request is not active yet and may be cancelled immediately

·                This request is pending and may be cancelled immediately

Request is current but not yet printed

The assumption is that no-one is yet searching for the item. The request is simply cancelled.

·                This request has not yet been printed and may be cancelled immediately

Request in process – and added to a batch of requests

If the request has been checked out from stacks and assigned to a batch of requests, then the cancellation will be set to “pending” and picked up when the batch is checked in at the reading room.

·                This request has already been batched and will be cancelled at the delivery location

Request is in-process – already en route to reading room

iIf the request is en route, and not at the reading room, then the request will be actually processed at the reading room i.e. it must be delivered all the way once it reaches its destination. The cancellation is applied as a “pending” cancellation.

·                This request has been dispatched and will be cancelled at the delivery location

See section regarding processing a pending cancellation at the reading room.

Request has not been processed at the stack location

If the cancellation is being initiated from a location other than the stack location, then a pending cancellation will be applied

·                This request has been printed and will be cancelled when checked out from the stack

If the cancellation is being initiated from the stack location, then the request can be cancelled, typically to cause the item to be returned to the shelves.

If the option “Allow other reservations to capture this item” is checked, then the next request in the queue will be activated. However, if the subsequent queue processing is to be interrupted, then all the other reservations will be set to Pending; thereby interrupting the normal flow through the system. If at some point, the requested item is then available to satisfy the requests, then these can be reset to active and the flow through the system can start again.

Postdated requests are NOT touched on the assumption that the problem will be resolved. If this is unlikely then these must be manually set to “unconfirmed status”.

Processing a pending cancellation at stacks checkout or checkin

A pending cancellation is only picked up when processed stacks checkout from the stack location (i.e. before it might become batched) or at checkin at the delivery location.

At the stack location, the item  is processed  as if the cancellation was originally being made from the stack location..

At the delivery location for a stack checkin, the item will either be trapped or set aside, as if it had been returned by the borrower. If it is requested that the reservations queue is NOT processed then the requests queued will be set to pending.

Interrupting the flow

For stack requests, the system does not change the temporary location of the item to the location last “found”. The item managing location will remain through the lifecycle of the request as its stack location. Any displays where location is relevant will show the item as “in transit from A to B” or “on loan at B”, “awaiting collection at B” and so on.

Where the request has been cancelled the item is either (still) at the Stacks location or recorded as “in transit” (back to the stacks location). If a loan status is applied to the item (e.g. Missing), then the in-transit status is removed and the item will appear simply as “Missing from the stack location”.

If the item needs to be relocated elsewhere, then it must be processed via AFO462/463 in the regular way. This will terminate any further processing via. the stack request processing control over the item's status and condition is relinquished to other aspects of the system.

Cancelling or suspending requests from the route

Options exist to suspend or cancel all requests for a route as part of the routes management definitions.

Suspensions ARE allowed for all items on a route. These only allow the requests to be “put into limbo". All readers may require notification that there may be a problem with their requests, in bulk.

Cancellations for a route are only allowed for requests which have not started their route to the reading room. This will cover those requests that are currently printed i.e. in the process of being collected or which have been checked in at the stack location.

6.2 Request batch maintenance[//]

Summary and details of the requests that have been batched can be accessed from the Stacks checkout and checkin functions.

Batches

The All batches command  lists all the current batches which relate to the current service point. As in other contexts, this means any batch which originated from, passed through or is destined for the current service point.

The display shows each batch number, the current processing status of the batch, the number of items making up the batch, where the items are going from and to, and whether it is “open” somewhere.

The “temporary suspension” command  allows the batch and all the items comprising it to be marked as suspended.

The “note” option allows a note to be added, amended or removed from the selected batch. This simply pops up  a form allowing input of the note.
Any such note is displayed whenever such a batch is checked in or out.

Selection of a specific batch leads to a listing of the items comprising the batch. This is in the standard form for the listing of requests.

A request which has been cancelled by the borrower is highlighted with a stop icon.

7. Locating and managing requests[//]

This section describes how requests are presented and retrieved in the system.

7.1 Summary display[//]

The main request menu AFO813 has two options. The Stack Request display option leads to a summary display of the requests for the current service point.

This presents a breakdown of the requests according to the current status of the request. A request will appear in all the service points pertinent to the request.

Selection of a specific line leads to a listing of the individual requests comprising the total shown, from which the individual request can be selected to get to the detailed display. However, for completed and rejected requests, the display will be limited to the most recent 500 requests..

The Print option allows you to print a listing of requests in the section, based on the mailmerge documents made available via AFO 815 – Request summary print setup.

The set of records labelled “Trapped” correspond to the items received at the service point, ready for either collection or delivery to specific tables .

From the reading room service point, if tables are defined, then the table number is included in the listing (which can then be printed as a guide to taking the items to the tables).

7.2 Searching[//]

The two options (Bibliographic search and Request search) allow specific searches to be made against the requests database.

The Bibliographic search brings up the standard search input form.

However, when the search is carried out, the system will automatically limit the search to those titles for which a request exists (or existed at any time!)

The Request Search command allows for a fairly complex search selection form:

Search term     is the expression to be used for the search

Search type     offers a dropdown list of various types.

Status              offers this dropdown list of possible requests statuses. For example

Dates

This set of four fields allows the user to define a date range – based on a specific type of date from the request.

This will limit the search to requests which are neither completed nor rejected – for example, if searching by borrower then only their current requests are displayed.

7.3 Specifics for searching[//]

By borrower

The search term for a borrower may be either the borrower barcode number or a name. If this is selected then this behaves as a regular borrower search, and either a unique match or a list of matching borrowers is returned.

When a specific borrower is selected, the system will effectively return the borrower record, from which the list of requests for that borrower may be selected.

By request id and service point

Searching by service point allows for the searching by the name of a defined service point OR by their code. Searching by name implies a right truncation (thus "Main" would find "Main service point") and if this is ambiguous (e.g. Main reading room, Main stack location) then a screen will offer a selection.

Searching by request id also implies right truncation – thus "ASR1" would find "ASR1", "ASR11" etc.

In either case, if the result generates multiple matches, then a summary listing, as shown in, will be displayed from which the user may selected a specific request.

By item barcode

This allows you to find the requests for a specific item barcode.

Displays from the borrower record – AFO 415

In AFO 415, Stack requests are displayed as part of the reservations summary display and are indicated as Stacks in the "Type" column.

Selection of a stack request line leads to the full display for the stack request record.

This is valid only for items which have a “review” status or which have not been “printed”.

Displays from the borrower record – AFO 431

At the top of the borrower overview screen, stack requests will be shown under Reservations (a total number in brackets):

On the borrower Detail screen, stack requests will be shown under Reservations:
In the header: Total no. of reservations: This is total number of reservations and the total number of Requests, Reservation request, Deleted, and Expired.
Line 3: Reservations: The totals here are only Current number of Reservations and only total number of Requests counts based on the parameter in AFO 815 – System wide options - How many days back to show request summary in 431.

8 Web OPAC functions[//]

8.1Overview[//]

From the point of view of the WebOpac, stack requests can be placed by using the existing Reserve button.

Once the option is chosen, the system will lead the borrower through a series of choices appropriate to the context of the holdings, and nature of those holdings, reservation or stack request available and may request the borrower to select between reservation and Stack request if the individual title is eligible for both..

WebOpac preferences, options include control as to which , and to enter a request for a title not found in the online catalogue but which they have reason to believe is actually available.

WebOpac preferences allow the site to  configure on a per profile basis policies regarding stack requests, including:

·                Availability of stack requests

·                Optional selection of service points / delivery points / tables

·                Optional ability to place requests on non-catalogued items

The details of these functions are described (assuming all options have been activated for the WebOpac Profile).

8.2 Placing a request[//]

 [Reserve] button selected: then the system checks to see whether the holdings comprise items at one or more stack locations.

If none of the material is at a stacks location, then the system drops into the regular reservation processing.

If the material is a mixture of stack and regular material, then the current screen will be repainted with the following special message at the top.

If Reservation is chosen, then the system continues with a regular reservation. The system now requires the user to identify themselves, as for placing a regular reservation

Stack material

The system determines the Stack items, the default delivery service point and shows the items available. The options and screens depend on the nature of the work (monographic or serial) and the details of the routes and items available.

The following example screens identify the possible permutations.

Monographic titles

In this case, there are two items in the stacks which may ONLY be delivered to “Main reading room”. Postdating requests is allowed.

The system displays the Stack location, the current availability status and an estimated delivery time for the item.

Availability for the second item, in this example, is shown simply as “Already requested” – specific details (e.g. In transit, Awaiting collection are not shown). If there is a further queue of reservations, the system will show Reservations in the queue : 4 in the Estimated delivery column.

In addition, the display shows the delivery location for the item. In this situation, this information is redundant, BUT as will be seen later this information can be relevant. In order to present as consistent an interface as possible, this column is shown even though it might be irrelevant in these particular circumstances.

If routes are defined to other reading rooms, the user is offered a choice of reading room.

In addition, the column under “Delivery location(s)” has now changed to a dropdown list, so that the user can see the delivery locations

In this example, ALL of the copies shown can be delivered to the same reading rooms

Finally, the screen above shows a fairly complex case – the first item can be delivered to the reading room and other locations, the second copy can only be delivered to the main reading room. The third copy however, from the Medical library stacks, can only be delivered to the Medical centre reading room – the Select button is therefore not offered.

Specific stack item selected

At this point the specific stack item is established.

Item available

Assuming that the item is available, then the following screen is offered

This form allows the user to post-date the request, and, if table numbers are in use, to select a table number.

If post-dating is allowed, and the user selects a date outside of the limits defined for the Stack Request code, then an error is shown

You may not enter a date earlier than 12 April 2008 or later than 12 May 2008 for a post-dated request.

Item not available

If the item is already requested, and in process, then the system will ask if they wish to place a reservation against the item, or to place a post-dated request on the item.

On confirmation of the request, the borrower is taken to the display of reservations to confirm that the request is placed.

Serials

The workflow for serials is slightly different because typically not every part is identified as an individual item. The borrower is therefore invited to select the holding at a particular location first, and then the selection is narrowed down to specific volumes.

Basically, user offered choice of selecting a unique issue if available, otherwise to enter a description of the part or parts required.

Non-catalogued material

If the option to enter a title not found in the catalogue is used, then the following dialogue is offered initially

After the borrower has logged in, then they must enter the information available.

Borrower self-registration

If borrower-registration is allowed the login screen is enhanced with the option to login as above.

A warning is displayed that they may continue to place their request but that this is subject to the validation of their credentials and that the library may choose to refuse membership and cancel the request.

The request placed will be left in a “review status”.

Displaying requests

Stack requests will be shown first, on the same listing as reservations, where the following column details are adjusted as follows.

Item number                              The Stack request number

Date Place                                The date placed or post-dated date
If the request is in Process, the estimated Date and time of delivery is available.

Position in queue                       Blank for an active  or post-dated request

Pickup location                          Delivery service point name and also a table number if defined.

Type fields                                 Blank if a request. Type wording set to “Request”

Title                                          If the request is for specific parts, then these will be shown as a second “line” of the title

If the request is active, then the row is extended with another row showing the status and estimated delivery time of the request.

Borrower  otices

Notices sent to the borrower are also be visible from the WebOpac. The system does not show the actual notice, but the event and message associated.. If there are any such notices for ACTIVE requests, which have not previously been displayed to the borrower, then a button labelled [Display important messages about your requests] is offered. Selection of this will lead to the display of the messages – for example :

9 Calculation of shipping periods[//]

This section describes in some detail the rules for calculating a shipping period. In the following we will discuss this in terms of a route from A to Z (where A may be a Stack or a reading room location) and Z must be the opposite..

Preliminaries

For both simple and complex calculations, the system checks to see if a route is defined for A to Z. If not then it uses the route defined for Z to A (and works backwards)

System calendars are defined for a specific period e.g. 01 Jan 2007 to 31 Dec 2010. This generates an entry for each day in that period … within the DAY, the system records the times available on that day ( e.g. from 9.00am – 13:00, 14:00 to 19:00)

In ALL cases below, if the calendar does NOT cover the day concerned, then the system deems the function to be available. In other words, the absence of a setting implies available (unlike many other situations where calendars are used).

Step 1 -Print calendar.

Determine when the request will be actually printed – the rest of the calculation cannot continue until the request is output.

If no print calendar and no print intervals are defined for the service point, the system assumes that the request appears immediately. Printing does NOT therefore contribute to the estimated delay.

If a print calendar is defined for A, then the system finds the nearest open period defined in the calendar. If the calendar ends, then the system assumes that the request can be printed at once.

This gives the earliest time it will be printed.

Step 2 – Print intervals

If any print intervals are defined, ( 15 mins past hour, 30 mins etc) – the system will move the estimated time forward to the next interval. Calendars are ignored for this purpose … (e.g. if Step 1 takes us to 17:22, and step 2 takes us to 17:30, then do not  check that the Print calendar is set to “available” at 17:30.

9.1 Simple Calculation[//]

If the Route end is defined for a route, then the simple  calculation is used, regardless of the possible settings elsewhere.

When no calendar is defined and no processing delay, then the time taken is zero.

Which settings to use depend very much on context – for a reading room attached to a library, it may just be sensible to set a print calendar and ignore the processing periods.

If only a calendar defined, then the system finds the next available time    When the calendar ends, assume available immediately.

If no calendar is defined but a processing period is defined, then the system simply adds the period defined to the date / time from the print interval step.

When  both calendars and a processing period are defined:.

·         -Ifthe period is in units of DAYS, then the system finds the next open date that period further on and sets the time to the opening time defined for that day.  Once the calendar ends, then the time will be set to 1 minute past midnight on the day reached.

--If the period is in hours or minutes, then the system converts this to a time.    If the calculated time spans over to the next day, the value of ‘Set to next open time on wrap around' is checked to see if the time is to be moved onto the next open day in the calendar.   Once the calendar ends,   the time is set to 1 minute past midnight.

9.2 Complex calculation[//]

The system follows each service point defined on the route (in reverse order, if appropriate). For each step , the system determines a date/time, and then uses this to determine the resulting date/time for the next step

The sequence of calculations is as follows, considering the calculation between locations P and Q within a route.      Calculate shipping period between P and Q

·                   Fix the time according to the defined arrival times at Q

·                   Calculate the processing time at Q

·                   Fix the time according to the defined delivery times from Q.

For the first location, if it is a Stacks location, we first calculate the Search time – the time taken to retrieve the item after the request printed. There is clearly NO shipping period to calculate, nor are the arrival times checked..

At the very end, we allow for the delivery time to a specific table, if allocated.

Processing times

If an overall time is defined, then this is used. If not, then there will be processing times defined for the item “in” and the item “out” (although these may be set to 0). If the overall time is defined, then this is always used; otherwise for an intermediate service point (.e.g. P or Q) then both times are used. For the starting point, only the “out” value is used; conversely at the end of the route only the “in” value is used.

Detailed calculation for Searching

Different “search” times can be defined for barcoded, non-barcoded (typically, journals) and uncatalogued items. If not defined, then the system uses the “barcoded” search time.

Different calendars can be defined for this – if not, the system uses the calendar for the (stack) location.

If the Search period is in Days, then the system finds the next open day beyond that and assumes that the time is set to the open time (for example, a Search period of 1 day effectively means “first thing tomorrow”).

If the period is in minutes or hours, then the system adds this on to the current time. If this takes us PAST the final closing time, then the system treats this as 1 day (i.e. first day tomorrow).  {For example, search time = 60 minutes, request printed at 15:30 takes us to 16:30, which is OK;  request printed at 17:45, would take us to 18:15 – but we are closed at 18:00, so the request will be found first thing on the next open day).

Processing times

Note that these are taken from the processing pattern associated with either the service point as a whole, or defined specifically for that particular place within a route.

The processing periods are calculated as for the Search periods i.e. try to add on the period to today's open hours, else jumps to the first opening time on the next appropriate day.

When processing “in” and “out” separately, these steps are undertaken individually. This might mean, for example, that the “in” step takes us to first thing tomorrow, and then the “out” stage takes us some hours further on….

In other words, the system does NOT add “in” and “out” and then calculate in one jump, but does them in two steps

Fixing to the delivery times

If specific delivery times are defined, then the system jumps the time forward to the next available delivery time. If no delivery time available “today”, then the system jumps forward to the next open day for the service point, and assumes the first delivery time on that day.

Shipping period

To establish the shipping period between P and Q, the system uses the Shipping period (to) defined for Q in the route OR the independent Shipping period defined for P<=>Q. The problem with using the period in the route is that going from P to Q uses the Q period, but going the other way uses the P period defined. (Unless the route back is explicitly defined!)

The defined period is simply added to the date/time calculated above. No calendars are used

Arrival times

If arrival times are defined, then we fix the date / time to the next arrival time, moving on the next open day for the service point, in similar fashion to the delivery times.

Delivery time to table

The delivery time to the table (defined in minutes) is added to the estimated delivery time. No checks on calendars are made for this.

9.3 Testing[//]

From the route, a test utility allows the user to see what dates are calculated using these rules.

Selecting the Test option leads a display of the form

so that different dates and times can be tried. The results are displayed

Showing the result of the calculation for each step of the route.

10 Request expiry[//]

Request reservations

The system makes a distinction between the default expiry date for a request for an available item and that when we need to place a reservation request.

The expiry date/period is associated with the Stack Request code (for example, the expiry periods may be different for academic staff or undergraduates).

And has two additional settings for “reservations”

            Reservation expiry period

            Reservation expiry date

These work on the same principle as the regular expiry period / date settings but are applied when the request is created as a reservation. (The expiry period is an actual period e.g. 20D (days), 18H (hours), whereas the Date is an explicit date- e.g. this might be set to the end of term.)

Expiry date and time for requests

In some situations, it is necessary to be more precise about the request expiry period. For example, the library may allow a borrower to place a request for an available item in the morning, and expect them to collect the book by the evening (let's say 18:00 that day).

In this situation, if the item is NOT collected by that time, the request is considered to be expired and the work is available for another borrower to request, with the implication that they can collect the book more or less immediately.

The expiry date and time is therefore particularly significant in this situation. The parameters in AFO 815 – Expiry date rules allow the date and time to be calculated precisely. The library can define a number of rules for the calculation of expiry date/times which can then be linked to stack request codes.

For each day of the week it is possible to define a range of times, followed by a rule for the calculation of the expiry date and time.

The rule may be entered in the form   d/mmm   or  d /hh:mm.

 Where 

            d          is the number of days to move forward

            mmm    is a number of minutes

            hh:mm  is an explicit time.

If this construction is used, then it would be expected that rules are defined that cover each and every day, and all hours of the day.

However, if the system does not find a day/time period, then the original style calculation of an expiry date (implying an expiry time of 23:59) will be used.

The rule defined can then be linked to the Stack Request code – by the field “Expiry period special rule” which offers a dropdown list of the special rules defined in AFO 815.

Lapse Period

In the original design of the system, when an item is trapped for the request (i.e. it becomes available for collection), then the original expiry date becomes irrelevant. The Lapse period setting takes over -.this tells the system for how long the work is to be held at the issue desk for the borrower to collect it.

For example – suppose the expiry date was 03 Feb 2010, and normally the item is held for 3 days for the borrower to come in to collect it. In this case, if the item is trapped on 02 Feb 2010, then it would be unfair to expire it on the 3rd.  The regular 3 days takes priority.

In order to cater for this in the enhanced environment, then for a regular request (i.e. for a title that was available immediately) the Lapse date and time will be set to the Expiry date; however for a reservation, the LAPSE period will be used.

In other words for the regular request, the borrower knows to collect the item more or less immediately (and there is no available notice); for a reservation request, a notice will be generated AND the request will be set to effectively expire according to the lapse period.

11 Example scenario[//]

Below is an example of how stack requests could be set up for a particular library. This is done by asking questions and then providing the answer that will get the desired result.

Various service points are defined:

Details of the BD service point:

Some general information about how stack requests are handled at the BD Stack:

What book locations are handled by the BD Stack ?

Where do books from the BD Stack go to ?

To CEN upstairs and also to the Central reading room:

How are books sent to the Central Reading room managed ?

How long does it take ?

What about the Van Delivery to Central shipping?

Central Library, here is the Reading room service point defined.

How long to FIND the books when the request is printed ?

How long does it take between BD and Central shipping?

How long does it take between Central shipping and reading room?

To get to the delivery table ?

Did we set the system up sensibly ?

·                     Document control - Change History

 

Version

Date

Change description

Author

1.0

July 2008

creation

 

2.0

June 2010

Various enhancements
part of 2.0.06 updates